Increases in vehicle complexity and the accompanying increase in maintenance costs have led to industry wide investments into the area of condition based health management (CBM). These efforts have led to the development of industry or equipment specific process solutions. However, conventional CBM systems are generally rigidly configured requiring the user to live with cumbersome performance or pay significant modification costs.
FIG. 1 is a simplified block diagram of an exemplary multi-level health maintenance process 10 that may be useful in monitoring the complex system (not shown). A complex system as discussed herein may be any type of vehicle, aircraft, manufacturing process, or machine that may utilize sensors, transducers or other data sources to monitor the various components and parameters of the complex system. The sensors/transducers are typically situated at the component or the process measurement level 20 to measure, collect and communicate raw data through a variety of data driven input/output (I/O) devices. This raw data may represent fault indicators, parametric values, process status, operating mode, and events, consumable usage and status, interactive data and the like. Non-limiting examples of other data sources may include serial data files, video data files, audio data files and built in test equipment.
Once the parameters of the complex system are measured, the measurement data is typically forwarded to more sophisticated devices and systems at an extraction level 30 of processing. At the extraction level 30, higher level data analysis and recording may occur such as the determination or derivation of trend and other symptom indicia.
Symptom indicia are further processed and communicated to an interpretation level 40 where an appropriately programmed computing device may diagnose, prognosticate default indications or track consumable usage and consumption. Raw material and other usage data may also be determined and tracked. Conventionally, diagnosis, prognostication and default indication is typically determined by applying detected parameters to a large centralized fault model 41, where data, processed data, or fused data is analyzed.
Data synthesized at the interpretation level 40 may be compiled and organized by maintenance planning, analysis and coordination software applications at an action level 50 for reporting and other interactions with a variety of users at an interaction level 60.
Although processes required to implement a CBM system are becoming more widely known, the level of complexity of a CBM system remains high and the cost of developing these solutions is commensurately high. Attempts to produce an inexpensive common CBM solution that is independent from the design of the complex system that is it is to monitor have been less than satisfying. This is so because the combination and permutations of the ways in which a complex system can fail and the symptoms by which the failures are manifested are highly dependent on the system design and the sophistication of the centralized fault model 41.
Conventionally, if additional data is required to determine the cause of a fault, a technician would manually author a data collection specification (i.e., subroutine) and upload it to the CBM system to collect data the next time the fault occurs. However, in some cases the data needed to diagnose the fault cannot be recreated until the fault is corrected. Thus, there exists a catch 22 scenario where technicians cannot fix a problem without additional data; and, the data cannot be obtained without first fixing the problem. One method to address this problem is to record all information at all times. Although such a scheme merely generates an overabundance of useless information that must be processed, stored and transmitted over a bus with finite bandwidth. However, there are certain failure modes for which the CBM node that monitors the asset experiencing the failure mode, or other CBM nodes, can obtain additional data in real time that will help identify the root cause of the failure and the corresponding corrective action. This provides higher fidelity diagnostic information than would be available with only the reported symptoms (aka fault codes, maintenance codes, diagnostic trouble codes, etc.). Such ancillary data collection is done “on condition” in order to reduce the data collection overhead, network bandwidth, CPU time, memory and other system resources. It captures the right data at the right time.
Accordingly, it is desirable to develop a health maintenance system architecture that is sufficiently flexible to support a range of complex systems. In addition, it is desirable to develop a health maintenance system that may be easily reconfigured by a user to allow ancillary data collection when a fault occurs and to automatically determine necessary supplemental data to be collected based on detected symptoms. Such a system dispenses with prohibitive reprogramming costs and delays. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description of the invention and the appended claims, taken in conjunction with the accompanying drawings and this background of the invention.